Supporting Differentiated Streaming Services in Heterogeneous Vehicle-to-Everything Networks

Advancements in assisted driving technologies are expected to enable future passengers to use a wide range of multimedia applications in electric vehicles (EVs). To address the bandwidth demands for high-resolution and immersive videos during peak traffic, this study introduces a bandwidth-management algorithm to support differentiated streaming services in heterogeneous vehicle-to-everything (V2X) networks. By leveraging cellular 6G base stations, along with Cell-Free (CF) Massive Multi-Input Multi-Output (mMIMO) Wi-Fi 7 access points, the algorithm aims to provide a high-coverage, high-speed, and low-interference V2X network environment. Additionally, Li-Fi technology is employed to supply extra bandwidth to vehicles with limited connectivity via V2V communication. Importantly, the study addresses the urgency and prioritization of different applications to ensure the smooth execution of emergency applications and introduces a pre-downloading mechanism specifically for non-real-time applications. Through simulations, the algorithm’s effectiveness in meeting EV users’ bandwidth needs for various multimedia streaming applications is demonstrated. During peak-bandwidth-demand periods, users experienced an average increase in bandwidth of 47%. Furthermore, bandwidth utilization across the V2X landscape is significantly improved.


Introduction
As assisted driving technology rapidly advances, future electric vehicles (EVs) will transcend their role as mere transportation devices, transforming into mobile offices and entertainment hubs.EVs will support various multimedia applications, enhancing in-car experiences.Notably, 360 • video technology will offer immersive viewing, allowing users to freely rotate their perspective and experience panoramic video.This innovation promises a new level of engagement for multimedia applications.Additionally, 360 • video calls for remote surgeries represent a groundbreaking telemedicine application [1], offering timely medical assistance and potentially saving lives.
Although multimedia applications provide EV passengers with rich entertainment and information, encoding technology is essential for efficient bandwidth and storage use.High-Efficiency Video Coding (HEVC) is widely used in fields like video surveillance and healthcare for its high-quality compression and fast processing [2], while Versatile Video Coding (VVC) offers significant bitrate reductions compared to HEVC and meets the demands of emerging media [3].However, VVC's higher complexity makes it unsuitable for real-time encoding [4].Despite its longer encoding times, VVC achieves a compression ratio 50% higher than HEVC while maintaining the same video quality [5].
The rise of Vehicle-to-Everything (V2X) communication marks a new era in vehicular interactions, enabling collaboration between vehicles and with infrastructure [6].As Sensors 2024, 24, 5007 2 of 30 demand for high-resolution and 360 • video grows, the V2X network must meet higher performance standards.The upcoming 6G network is set to provide the needed improvements, offering faster, more reliable connections, greater bandwidth, and lower latency [7].Operating across a wide range of frequencies, including millimeter waves (mmWave), sub-6GHz, terahertz (THz), and visible light [8], 6G will ensure a smooth and efficient multimedia experience in V2X network environments.
Light Fidelity (Li-Fi) technology, which uses visible light for wireless communication, has gained significant attention for its ultra-high-speed data-transmission capabilities.By rapidly modulating LEDs, Li-Fi can achieve fast audio and video transmission [9].Future EVs could use Li-Fi through headlights for vehicle-to-vehicle (V2V) communication [10].In the literature, Saranya et al. [11] utilized embedded sensors and control units, employing Li-Fi technology to address challenges in the vehicular environment.They claimed that Li-Fi is most suitable for vehicle wireless communication compared to other wireless communication methods.Yahia et al. [12] improved visible light V2V systems by integrating biconvex and plano-concave lenses to enhance imaging receiver performance.
Beyond the visible light spectrum, the terahertz band stands out as a key frequency range for 6G.It provides ample spectrum resources capable of supporting extremely high data transfer rates [13], making it particularly well-suited for V2X applications.Recent studies have addressed the challenge of supporting V2X with THz technology.Li et al. [14] studied joint sensing and communication in THz V2X and vehicle connectivity issues.They proposed a dynamic graph neural network (GNN) model that selects suitable graph information aggregation functions based on the V2X network topology.This model enhances the extraction of V2X information and increases the capacity of THz services to serve more vehicles.Chang et al. [15] introduced a joint communication and control algorithm for beam alignment in mmWave/THz V2X networks.Their work focused on analyzing the beam alignment process for transmissions from the base station to the vehicle.Rashee and Hu [16] presented an innovative V2X routing approach that leverages Cognitive Radio and Software Defined Networking (SDN) to achieve ultra-high data rates.This method employs predictive routing to intelligently switch between mmWave and THz frequencies.
However, the communication range of THz is relatively short [17], necessitating collaboration with other frequency bands to address its limitations.Wi-Fi 7, recently acclaimed, is a promising option.Operating in unlicensed frequency bands, Wi-Fi technology provides various cost-effective user devices and access points [18].Wi-Fi 7 will support 320 MHz bandwidth channels and utilize 4096 Quadrature Amplitude Modulation (QAM) to enhance transmission rates [19].Additionally, Wi-Fi 7 will feature multi-link operation, which improves throughput and transmission reliability and reduces latency by unifying and coordinating link management [20].
With the development of wireless communication technologies, Cell-Free (CF) Massive Multi-Input Multi-Output (mMIMO) technology has emerged to address the limitations of traditional cellular networks.In CF mMIMO systems, all access points are connected to an access point control unit via fronthaul links.These control units, which can be interconnected directly or through the core network, analyze system performance, provide real-time feedback, and manage baseband signals, supporting user-centric transmission [21].A subset of access points can collectively serve a group of devices on the same time-frequency resources, enhancing signal power and reducing interference [22].This architecture facilitates seamless communication channel switching and is highly suitable for V2X networks and hotspot coverage [23].Scholars have advocated for the implementation of CF mMIMO in V2X contexts.Zhang et al. [24] introduced a beam alignment technique employing broad learning-assisted CF mMIMO at both user and access-point terminals, conducting simulations to assess user mobility in V2X environments.Kurma et al. [25] thoroughly investigated the robustness of CF mMIMO for V2X networks.Their findings highlight the significant impact of various system parameters on performance, including the transmit power, vehicle mobility, channel state information accuracy, fronthaul link quality, and more.
• This study utilizes advanced technologies of wireless communication, including mmWave, sub-6GHz, and THz waves, to deliver higher transmission rates.It also deploys CF mMIMO architecture Wi-Fi 7 access points in congested areas to boost communication reliability, enhance transmission rates, and minimize interference.
Through the integration of these advanced network technologies, this study aims to create a robust V2X network environment for EV users.• This study categorizes multimedia applications based on their characteristics and assigns bandwidth allocation priority accordingly.Bandwidth is sourced from base stations and CF mMIMO access points to prioritize emergency applications lacking sufficient resources.Once emergency applications are adequately addressed, bandwidth is then allocated to real-time applications to ensure they receive satisfactory bandwidth.Additionally, Li-Fi is utilized for V2V communication, allowing EVs with limited bandwidth to access bandwidth from base stations and access points on less-congested road segments via inter-vehicle communication.Lastly, if bandwidth remains insufficient, the study dynamically adjusts video frame rate and resolution based on the type of multimedia application to reduce bandwidth requirements.• This study proposes a pre-download strategy for non-real-time applications at less congested road segments.EVs download additional video segments anticipated for future playback when the base station or CF mMIMO access point at the passing road segments has sufficient bandwidth.The algorithm dynamically adjusts the bandwidth allocated to vehicle users based on the number of upcoming video segments to be played on the EV.This ensures that each user of non-real-time applications can prestore a sufficient number of video segments.By leveraging the remaining bandwidth of the base stations and the CF mMIMO access points at less congested road segments, this approach achieves improved overall bandwidth efficiency.

Optimizing Bandwidth Allocation for Multimedia Applications in V2X Networks
To reduce the computational complexity of traditional centralized control architectures, a decentralized computational framework is adopted, as shown in Figure 1.Base stations operating across THz, millimeter-wave, and sub-6GHz frequency bands are strategically positioned along all road segments to serve as bandwidth sources for multimedia applications.To address the high deployment costs associated with densely placing access points and antennas in a CF mMIMO architecture, Wi-Fi 7 access points featuring CF mMIMO technology are selectively deployed solely on streetlights along congested road segments.Each congested road segment is equipped with a CF mMIMO access point control unit, to which all access points on the corresponding road segment are connected.These control units utilize real-time data collected from roadside units (RSUs) on the respective road segments to manage control and coordination.This approach enhances the effective selection of suitable access points for EV users on the same road segment, forming subsets of access points to ensure seamless connectivity, broader signal coverage, and efficient resource allocation.future playback when the base station or CF mMIMO access point at the passing road segments has sufficient bandwidth.The algorithm dynamically adjusts the bandwidth allocated to vehicle users based on the number of upcoming video segments to be played on the EV.This ensures that each user of non-real-time applications can pre-store a sufficient number of video segments.By leveraging the remaining bandwidth of the base stations and the CF mMIMO access points at less congested road segments, this approach achieves improved overall bandwidth efficiency.

Optimizing Bandwidth Allocation for Multimedia Applications in V2X Networks
To reduce the computational complexity of traditional centralized control architectures, a decentralized computational framework is adopted, as shown in Figure 1.Base stations operating across THz, millimeter-wave, and sub-6GHz frequency bands are strategically positioned along all road segments to serve as bandwidth sources for multimedia applications.To address the high deployment costs associated with densely placing access points and antennas in a CF mMIMO architecture, Wi-Fi 7 access points featuring CF mMIMO technology are selectively deployed solely on streetlights along congested road segments.Each congested road segment is equipped with a CF mMIMO access point control unit, to which all access points on the corresponding road segment are connected.These control units utilize real-time data collected from roadside units (RSUs) on the respective road segments to manage control and coordination.This approach enhances the effective selection of suitable access points for EV users on the same road segment, forming subsets of access points to ensure seamless connectivity, broader signal coverage, and efficient resource allocation.on their application levels: emergency application, real-time applications, and non-realtime applications.

•
Emergency applications, such as 360 Notably, both emergency and real-time applications utilize High Efficiency Video Coding (HEVC) due to its lower encoding complexity [2], while non-real-time applications employ Versatile Video Coding (VVC) for its higher compression rates [5].
In our algorithm, EV users plan their routes with assistance from an onboard system installed in the EV prior to departure.Once the user sets the destination, time, and departure location, the "Real-Time Traffic and Travel Time Calculation" module is activated.This module calculates the most suitable route based on the EV user's preferences and uploads the travel time for each segment to the RSUs along the route.
When an EV user starts a multimedia application, the roadside units (RSUs) along the EV's route are notified of the multimedia application requirements and vehicle information.The RSUs then contact their respective CF mMIMO access point control units to coordinate the access points, allocating bandwidth to each application accordingly.If the EV moves outside the coverage area of access points in the CF mMIMO architecture or the allocated bandwidth by the access points is insufficient, the managing RSUs request bandwidth for the vehicular multimedia application from the base stations along its route instead.In scenarios where the multimedia applications of EV users cannot meet their bandwidth requirements while driving through specific congested road segments, the EV requests the RSUs managing those segments to locate other EVs that can form a fleet to forward the bandwidth from CF mMIMO access points or base stations from less congested road segments.Notably, Li-Fi technology is utilized for V2V communication within the fleet to assist in forwarding the required bandwidth for multimedia applications.
If EV users initiate multimedia applications while the EV is in motion, the "Multimedia Application Bandwidth Adjustment" module is activated.This module interfaces with the multimedia application software provider's server to obtain the relevant specifications and requirements.The multimedia application quality settings provided by the server, along with user requirements set by EV users, are then uploaded to the RSUs along the route.Based on the type of multimedia application, the RSUs activate either the "Emergency/Realtime Application Bandwidth Assignment" module or the "Non-Real-Time Application Download" module.
When an EV is within the communication range of access points in the CF mMIMO architecture, the application quality settings and user requirements are communicated to the CF mMIMO access point control units through the RSUs.The control units select and form clusters of access points to serve the EV users, prioritizing bandwidth for emergency/real-time applications.If certain clusters of access points cannot meet the bandwidth requirements of the multimedia applications during rush hours, or if the EV is not within the communication range of access points in the CF mMIMO architecture, the RSUs will request the base station(s) in the covered road segment to support the bandwidth demand of the multimedia applications.
Moreover, if bandwidth is still available, the non-real-time applications can pre-fetch additional video segments by utilizing the remaining bandwidth.This pre-fetching process ensures a smooth multimedia experience for users, even when the EV is not within the coverage range of CF mMIMO architectures and base stations later along the route.The bandwidth allocated from base stations and CF mMIMO access points is dynamically adjusted based on the remaining video segments stored on the EV.
In cases where the base stations and CF mMIMO clusters along the managed route segment cannot provide sufficient bandwidth for EV passengers, the "Emergency/Real-time Application Bandwidth Assignment" module prioritizes emergency and real-time applications by reallocating bandwidth initially assigned to VoD applications.If the bandwidthdemanding applications still face a deficit, the managing RSU activates the "V2V Bandwidth Forwarding" module.This module facilitates V2V communication to forward available bandwidth from base stations or the CF mMIMO architecture located in uncongested segments.Initially, the managing RSU in the bandwidth-deficient road segment will form an EV fleet based on its real-time traffic database and assist in harvesting bandwidth from base stations or CF mMIMO access points in less congested segments.
This work periodically tracks the quality of multimedia application usage for EV passengers.During peak hours, if there is a need to downgrade the quality of these applications, the "Multimedia Application Bandwidth Adjustment" module will be activated.This module adjusts the frame rate of multimedia applications to reduce bandwidth requirements and determines whether to change the resolution based on the application's characteristics.Emergency applications, due to the critical nature of their functions, such as maintaining accuracy in remote surgery, will not be subjected to resolution reduction.They will always be prioritized in bandwidth reallocation to ensure sufficient bandwidth availability.If bandwidth is insufficient, the bandwidth initially allocated to real-time and non-real-time applications will be reassigned to emergency applications.Specifically, real-time and non-real-time applications will have their resolution adjusted in a timely manner to reduce bandwidth requirements, thereby avoiding interruptions in playback due to bandwidth reduction.
The detailed descriptions of each module are as follows:

Real-Time Traffic and Travel Time Calculation
This module is activated before the EV commences its journey.Once the EV passenger enters the destination information, time, and departure location into the onboard system, the EV initiates its journey.Initially, this module utilizes historical road traffic information from the EV database.Leveraging the potential of machine learning techniques to accurately predict driving times on roads [32,33], this module adopts support vector regression (SVR) technology [32] to estimate the travel time for each road segment based on the historical data of the EV.This process generates routes that align with the driving preferences of the EV user.
Subsequently, this module obtains real-time traffic information for each road segment of the route from the corresponding RSUs to determine the EV's arrival times at all road segments along the route.Taking into account that the EV passengers might change their itinerary at the last minute or that factors like yielding to emergency vehicles might affect the arrival times and driving speeds compared to previously estimated times, this module recalculates the arrival times for each segment based on the latest traffic conditions upon arriving at the next intersection along its route.When there are significant deviations in the arrival times of the road segments compared to the initial estimates, this module reports the updated arrival times to the corresponding RSUs.The traffic condition information kept at each RSU is then adjusted accordingly.
The flowchart of this module is illustrated on the left side of Figure 2, and the execution steps are outlined below: Step 1: After setting the departure time, location, and destination, this module calculates the most suitable route for the EV user's preferences as follows: subject to the following:

No
Does the frame rate hit the lower limit?

Yes
Decrease the resolution using Equations ( 14)- (15) Decrease the frame rate using Equations ( 12)- Step 1: After setting the departure time, location, and destination, this module calculates the most suitable route for the EV user's preferences as follows: subject to the following: ,  = ( ,,1  ,  ,,2  , ⋯ ,  ,,ℎ , ,, The parameters are as follows: (i) Equation ( 1) selects the optimal route tailored to the preferences of the EV passenger.The Min (•) operation takes three parameters in sequence: the total distance traveled by the EV from the departure location to the destination, the congestion pricing for controlled road segments during peak hours, and the travel time required to reach the destination, including any intermediate waypoints that EV σ must pass through.EV passengers can adjust the weighting values of ω σ 1 , ω σ 2 , and ω σ 3 based on their preset preferences.
(ii) This module constructs the l-th candidate route R σ l for the EV according to the intermediate stopping points planned by the EV user, such as purchasing meals, household items, or picking up colleagues along the route, etc. R σ l,i represents the driving route from the (i − 1)-th stopping point to the i-th stopping point for σ, where φ σ is the number of stopping points along the route from the departure location to the destination for σ.
(iii) Org and Dst represent the positions of the starting point and destination, respectively.
For the candidate route indexed by l, c σ l,1,1 denotes the starting point, c σ l,i,h σ l,i indicates the i-th intermediate stopping point, and c σ l,φ σ ,h σ l,φ σ represents the final destination.sl c σ l,i,j ,c σ l,i,j+1 denotes the length of the connecting road segment between two intersections, c σ l,i,j and c σ l,i,j+1 .rt c σ l,i,j is the time when the EV arrives at intersection c σ l,i,j , while rt σ Org and rt σ,max Dst , respectively, represent the departure time of the EV and the latest acceptable time for the EV user to arrive at the destination.
represents the congestion pricing implemented for the road segment between intersections c σ l,i,j and c σ l,i,j+1 at the time rt c σ l,i,j when the EV arrives.If the EV does not pass through any toll road segments or if it arrives at c σ l,i,j during off-peak hours, the value of denotes the time spent by the EV to pass through the road segment connecting c σ l,i,j and c σ l,i,j+1 after arriving at c σ l,i,j at time represents the time required for the EV to enter the road segment connecting c σ l,i,j and c σ l,i,j+1 after arriving at c σ l,i,j at time rt c σ l,i,j due to possible traffic control, and is the time spent by the EV at the intermediate stopping point . Here, the and is used to control whether the road segment connecting c σ l,i,j and c σ l,i,j+1 allows the EV to pass at time rt c σ l,i,j .For example, during peak hours, if the traffic control center designates the road segment between c σ l,i,j and c σ l,i,j+1 as a key controlled segment and prohibits the EV from driving on it, then ξ c σ l,i,j ,c σ l,i,j+1 rt c σ l,i,j is set to 1; otherwise, it is set to 0.
Step 2: Upon arriving at the next intersection along its route, EV σ requests the latest traffic information for the remaining road segments from the corresponding RSUs.It then updates its estimated arrival times at the remaining intersections on the route accordingly: where rt c σ l,i,j is the updated arrival time at intersection denotes the time that the EV traverses the road segment connecting c σ l,i,j and c σ l,i,j+1 after arriving at c σ l,i,j at time rt c σ l,i,j , and denotes the time spent at the intersection c σ l,i,j due to traffic control after arriving at time .
Step 3: Compare the calculated arrival times of the EV at each road segment to the originally expected times and check if they exceed the system's predefined threshold value ϵ: where rt c σ l,i,j and rt c σ l,i,j represent the originally predicted arrival time and the updated estimated arrival time for EV σ at intersection c σ l,i,j , respectively.∆ is the time slot interval, cp σ denotes the road segment currently being traversed by the EV, and ϵ is a constant predefined by the system.
Step 4: If dat σ p σ j = 1, then notify the RSU responsible for the road segment of the adjusted arrival time.
Step 5: Switch to background execution mode.
Step 6: If the destination has not yet been reached, the module will go back to Step 2 and continue execution before arriving at each road segment along the route.
Step 7: If the EV encounters emergency vehicles, such as ambulances or police cars that need to be yielded to, or if delays occur due to traffic congestion along the driving route, this module will return to Step 4 to recalculate the arrival times for each remaining road segment before proceeding to the next intersection.
Step 8: If the EV passenger makes a last-minute change to the itinerary, this module will return to Step 1 to recalculate the most appropriate driving route starting from the current location.

Multimedia Application Bandwidth Adjustment
When an EV passenger initiates a multimedia application while the EV is in motion, this module retrieves the application's specifications from the multimedia-applicationprovider's server.It then uploads these specifications to the RSU along the driving route and notifies the corresponding RSU to activate the bandwidth-allocation module according to the type of application used by the EV passenger.Additionally, this module addresses bandwidth supply-demand imbalances during peak hours by dynamically reducing the frame rate or decreasing the video resolution of applications.However, to ensure that critical applications, such as remote surgeries, are not affected by resolution reduction that could lead to operation faults, this module will maintain the resolution of emergency applications unchanged.This approach prioritizes the accuracy and reliability of emergency applications while ensuring the equitable allocation of bandwidth resources to address the different requirements of various applications, particularly under resource constraints.
The flowchart of this module is illustrated on the right side of Figure 2, and the execution steps are outlined below: Step 1: After the multimedia application is launched, this module retrieves the relevant specifications and requirements of the application from the server of the multimedia application provider.
Step 2: This module uploads the driving times of the EV on each road segment, as well as the requirements and specifications of the multimedia application, to the RSU of the corresponding road segment.
Step 3: If the multimedia application type used by the EV passenger is for emergency or real-time purposes, the "Emergency/Real-time Application Bandwidth Assignment" module is activated.Conversely, the "Non-Real-Time Application Download" module is activated.
Step 4: If the multimedia application's bandwidth requirements can be met, advance to Step 8 of the process.
Step 5: If the frame rate of the multimedia application used by the EV passenger has not decreased to the preset minimum, then reduce the frame rate as follows to decrease its bandwidth requirements: where ursu t σ,v j and ddrsu t σ,v j designate upload and download bandwidth insufficiencies, respectively, for EV σ traverses at time slot t σ,v j .t σ,v 1 and t σ,v e σ,v represent the times when application v starts and ends.Additionally, p σ i represents the i-th junction along the route, and p σ h σ stands for the endpoint of the route.f v denotes the minimum frame rate of the Sensors 2024, 24, 5007 10 of 30 application preset by the system for the EV passenger, and vf f σ,v represents the streaming frame rate requirement set by the EV passenger at level f σ,v .
Step 6: If the application used by the EV passenger is for real-time/non-real-time purposes and the resolution is not equal to the preset minimum value, then reduce the resolution of the real-time/non-real-time application as follows to decrease its bandwidth requirements: where r v represents the minimum resolution of the application set by the system for the EV passenger, while vr q σ,v stands for the expected resolution requirement of the screen at level q σ,v set by the EV passenger.
Step 7: If adjustments to the frame rate or resolution of the application have been made in the preceding steps, return to Step 2 to resume the bandwidth allocation process.Otherwise, inform the EV passenger that the bandwidth requirements cannot be met.
Step 8: This module operates in the background.
If the multimedia application used by the EV passenger is for emergency or real-time purposes, this step verifies whether the EV passenger changes the itinerary temporarily or if there is a significant deviation between the arrival times at the passing-by road segments and the originally estimated times.In such cases, the "Real-Time Traffic Conditions and Travel Time Calculation" module is activated to recalculate the driving route or the times of arrival at segments along the route.The process then proceeds back to Step 2 to resume.
As for VoD applications, if the pre-downloading is complete, this module will stop execution.Otherwise, the RSU responsible for the next road segment is notified, and Step 3 is executed.

Emergency/Real-Time Application Bandwidth Assignment
This module first attempts to allocate bandwidth for emergency and real-time applications based on whether the EV is within the coverage area of a CF mMIMO architecture.If the EV is within this coverage area, the RSU will notify the corresponding CF mMIMO access point control unit.This control unit will then use a clustering algorithm, as described in [34], to group appropriate access points into a cluster that prioritizes bandwidth allocation for the emergency or real-time applications.Notably, if the CF mMIMO access point control unit cannot provide sufficient bandwidth, the RSU will request additional bandwidth from the base station(s) in the covered road segment.
If the EV is not within the coverage area of any CF mMIMO architecture, the RSU will check whether the base stations along the route can provide the necessary bandwidth for the emergency or real-time application.If none of the base stations within the EV's communication range can provide sufficient bandwidth, the RSU will examine whether these base stations can reallocate bandwidth initially allocated to non-real-time applications.If bandwidth reallocation is performed but the requirements for emergency or real-time applications remain unsatisfied, the RSU will activate the "V2V Bandwidth Forwarding" module to obtain bandwidth from base stations or CF mMIMO architectures in less congested areas.Given that emergency applications should have the highest priority for bandwidth allocation, if the V2V bandwidth forwarding still cannot meet the bandwidth demands for emergency applications, the bandwidth initially allocated to real-time applications will also be reallocated to the emergency applications.
Figure 3 illustrates the flowchart of this module, and the execution steps are outlined below: congested areas.Given that emergency applications should have the highest priority for bandwidth allocation, if the V2V bandwidth forwarding still cannot meet the bandwidth demands for emergency applications, the bandwidth initially allocated to real-time applications will also be reallocated to the emergency applications.
Figure 3 illustrates the flowchart of this module, and the execution steps are outlined below: Step 1: If the EV is not within the coverage area of any CF mMIMO architecture, advance to Step 9.
Step 2: Upon receiving the bandwidth allocation request, the managing CF mMIMO access point control unit employs an access point clustering algorithm from the literature [34] to select appropriate access points.These selected access points form a cluster to serve the EV passenger.
Step 3: Considering the time that the EV spends on the passing road segments and the specifications of an emergency or real-time application set by EV passengers, the required bandwidth for the application during each time slot is calculated.Specifically, the total bandwidth available from the access point cluster serving the application is examined to determine if it meets the minimum bandwidth requirements for emergency or real-time applications as follows: where the binary indicator γ σ,v represents whether the emergency/real-time application v is a bidirectional application.A value of γ σ,v = 1 indicates that the application is bidirectional, while a value of γ σ,v = 0 indicates that the application is unidirectional.The start and ending time of v are respectively denoted by t σ,v 1 and t σ,v e σ,v .p σ i indicates the i-th intersection index along the driving route, while p σ h σ represents the destination.ub ϑ σ,v t σ,v j and db ϑ σ,v t σ,v j are used to denote bandwidth for uploading and downloading that ϑ σ,v , a member of the access point cluster, can allocate to the bidirectional application v when EV σ passes through the transmission range of ϑ σ,v during time slot t σ,v j .ur t , respectively, represent the RSU managing the road segment p σ i where the EV experiences insufficient bandwidth uploading and downloading during time slot t σ,v j .The application streaming resolution can be categorized into q v levels, while vr q σ,v denotes the EV passenger's expected streaming resolution for level q σ,v .Similarly, the frame rate of the application can be categorized into f v levels, while vf f σ,v denotes the frame rate expected by the EV passenger for level f σ,v .
Step 4: If the access point cluster can satisfy the minimum bandwidth requirements of the emergency or real-time application, the access point control unit should be notified to allocate the bandwidth to the application, and this module will conclude.Otherwise, advance to the subsequent step.
Step 5: The access point control unit reallocates the bandwidth to the demanding emergency or real-time application from that initially assigned for other non-real-time applications: where the designated non-real-time application is indexed by µ, and θ µ denotes a member of the access point control unit responsible for allocating bandwidth to µ.The bandwidth that can be reallocated from non-real-time applications are denoted as bub t σ,v j for upload and bdb t σ,v j for download.
Sensors 2024, 24, 5007 13 of 30 Step 6: If either of bub t σ,v j or bdb t σ,v j obtained from the previous step is not equal to zero, it implies that the bandwidth originally allocated by the member θ µ of the access point control unit to non-real-time application µ is reassigned to the demanding emergency or real-time application.Accordingly, this step invokes the "Non-Real-Time Application Download" module to assist in downloading the expected video segments for the non-realtime application if either of bub t σ,v j or bdb t σ,v j is not zero.
Step 7: Check whether the emergency or real-time application meets the minimum bandwidth requirements.If satisfied, the result is sent back to the EV and the module will conclude.Otherwise, advance to the subsequent step.
Step 8: If either of dub t σ,v j or ddb t σ,v j obtained from Equations ( 25) and ( 27) is less than zero, the bandwidth-demanding application still has a deficit.The following equations evaluate whether the base station's signal coverage area can meet the bandwidth requirements for emergency or real-time applications: where φ σ,v is the index of the base station that provides bandwidth to the application.
Step 9: Check whether the emergency or real-time application meets the minimum bandwidth requirements.If satisfied, the result is sent back to the EV and the module will conclude.Otherwise, advance to the subsequent step.
Step 10: Request the base stations that have assigned bandwidth to non-real-time applications to reallocate it to the emergency or real-time application: where the designated non-real-time application is indexed by µ, and φ µ is the base station responsible for allocating bandwidth to µ.
Step 11: If either bub t σ,v j or bdb t σ,v j is not equal to zero, this step invokes the "Non-Real-Time Application Download" module to assist in harvesting the bandwidth that was initially assigned to non-real-time applications.
Step 12: Upon satisfying the bandwidth demands, the result is returned to the EV, and this module will conclude.Otherwise, advance to the subsequent step.
Step 13: The RSU activates the "V2V Bandwidth Forwarding" module to search for base stations or CF mMIMO access points that can provide bandwidth and relay the bandwidth to the demanding emergency/real-time application via V2V communication.
Step 14: The result is returned to the EV if the bandwidth requirement is met, and then, this module will conclude.Otherwise, advance to the subsequent step.
Step 15: If the multimedia application used by the EV passenger is an emergency application, move on to the next step.Otherwise, the result is returned to the EV, and then, this module will conclude.
Step 16: Reassign the bandwidth that was originally assigned to other real-time applications by all base stations within the signal coverage area of the EV during the same time period to the emergency applications.
Step 17: If any bandwidth that was originally assigned to other real-time applications is reassigned, activate the "V2V Bandwidth Forwarding" module to harvest bandwidth for the real-time applications.
Step 18: Return the result to the EV, and then, this module will conclude.

Non-Real-Time Application Download
Leveraging the ability to pre-generate and store segments of non-real-time applications on the supplier's server, an EV can preload upcoming video segments into its onboard storage from base stations or access point clusters along the road segments it travels.This preloading can occur while non-real-time application video segments are being played.If the EV is within the coverage area of any access points in a CF mMIMO architecture, the managing CF mMIMO access point control unit will use a clustering algorithm, as detailed in [34], to select appropriate access points for forming a cluster to preload segments for the non-real-time application.However, if the access point cluster cannot provide sufficient bandwidth or if the EV is out of range of the CF mMIMO architecture, the managing RSU will request additional bandwidth support from the base stations serving that road segment.If the allocated bandwidth is still inadequate to preload segments before their scheduled playtime, the "V2V Bandwidth Forwarding" module will be activated to obtain additional bandwidth from CF mMIMO access points or base stations located in less congested road segments.
Figure 4 illustrates the flowchart of this module, and the execution steps are outlined below:  Step 1: If the EV is not within the coverage area of a CF mMIMO architecture, advance to Step 6 of the process.
Step 2: The CF mMIMO control unit utilizes an access point clustering algorithm, as described in literature [34], to identify suitable access points for forming a cluster.
Step 3: The CF mMIMO cluster preloads application segments according to the specifications of the non-real-time application as follows: , , , , Step 1: If the EV is not within the coverage area of a CF mMIMO architecture, advance to Step 6 of the process.
Step 2: The CF mMIMO control unit utilizes an access point clustering algorithm, as described in literature [34], to identify suitable access points for forming a cluster.
Step 3: The CF mMIMO cluster preloads application segments according to the specifications of the non-real-time application as follows: c σ,v denotes the downloading segment and τ c σ,v denotes the time, db ϑ σ,v τ c σ,v represents the bandwidth allocated to application segment c σ,v during time τ c σ,v over ∆ time slots, and ϑ σ,v is a member of the CF mMIMO access point.δ signifies the number of consecutive time slots for segment downloads after time τ c σ,v .C σ,v is the total number of segments in the non-real-time application.The playback time of c σ,v is denoted by cpt σ,v c σ,v , while CS c σ,v (•) stands for the bit rate of c σ,v .Additionally, c f r c σ,v , cbr c σ,v , and cd c σ,v represent the frame rate, resolution, and playback duration of video segment c σ,v , respectively.The start and stop times of the non-real-time application are denoted by cpt σ,v 1 and cpt σ,v c σ,v , respectively, and br q σ,v is the resolution requirement set by the EV user for video frame q σ,v .The EV will start playing the non-real-time application after arriving at intersection p σ 1 , and rt p σ 1 is the time when the EV arrives at intersection p σ 1 .bu f σ τ c σ,v denotes σ's remaining buffer at time τ c σ,v , and bu f σ represents the size of σ's buffer.
Step 4: Once all segments for the non-real-time application being played by the EV passenger have been successfully downloaded, the EV will be notified of the completion, and then, the module will conclude.Otherwise, advance to the subsequent step.
Step 5: The execution returns to step 3 to resume operation if the CF mMIMO cluster is capable of satisfying the minimum bandwidth requirements for pre-downloading nonreal-time application content to the EV.
Step 6: All base stations within the EV's communication range are instructed to allocate bandwidth to pre-download application segments to the fullest extent possible: where db φ σ,v τ c σ,v represents the bandwidth allocated by base station φ σ,v to non-real-time application segment c σ,v during the time period τ c σ,v over ∆.
Step 7: Once all segments of the non-real-time application being played by the EV passenger have been successfully downloaded, the EV will be informed of the completion, and the module will conclude.
Step 8: If the EV encounters difficulties in smoothly downloading non-real-time application segments due to inadequate bandwidth within its signal coverage area from the base stations, the "V2V Bandwidth Forwarding" module is activated.This module identifies base stations and CF mMIMO clusters situated in less congested road segments to acquire the required bandwidth for preloading.Afterwards, the bandwidth is relayed through V2V communication.
Step 9: The outcome is communicated to the EV passenger.Following this, the module completes its execution.

V2V Bandwidth Forwarding Module
When the RSU receives notification from an EV indicating that the required bandwidth for multimedia applications cannot be met, it initiates a connection between the requesting EV and other EVs within the V2V communication range.The last EV in the fleet can obtain the bandwidth from CF mMIMO clusters or base stations over less congested road segments.Subsequently, the collected bandwidth is transmitted from the last EV in the fleet to the requesting EV via Li-Fi for V2V communication.This cooperative approach ensures that the requesting EV can effectively support multimedia applications for its passengers and efficiently utilize the bandwidth of base stations and CF mMIMO clusters on uncongested road segments.
Figure 5 illustrates the flowchart of this module, and the execution steps are outlined below:  Step 1: To support the bandwidth requirements of the EV passenger's application, the managing RSU first queries other RSUs on uncongested road segments to identify base stations and CF mMIMO clusters that can offer bandwidth.It then creates connections between vehicles in the vehicle chain.
subject to the following: Step 1: To support the bandwidth requirements of the EV passenger's application, the managing RSU first queries other RSUs on uncongested road segments to identify base stations and CF mMIMO clusters that can offer bandwidth.It then creates connections between vehicles in the vehicle chain.
subject to the following: where R σ,v s represents the s-th fleet capable of forwarding bandwidth for application v, S σ,v is the number of fleets supporting v, and the length of fleet s is denoted by η σ,v s .r σ,v s,1 and r σ,v s,η σ,v s represent the EV indexes at the beginning and end of the fleet s, respectively.
φ r σ,v s,1 and φ σ represent the index value of the CF mMIMO cluster member or base station located at the origin of the fleet, respectively.p σ h σ is the destination of EV σ, and σ cannot support the required bandwidth for v when passing through the k-th segment between p σ k and p σ k+1 .The symbols t σ,v 1 and t σ,v e σ,v , respectively, represent the times when v starts and ends.When the binary flag γ σ,v is set to 1, it signifies that v is bidirectional, while the binary flags α t σ,v j and β t σ,v j represent the segment where the bandwidth for uploading and downloading v are inadequate at time t σ,v j , respectively.urb for the remaining bandwidth available for upload and download from EV r σ,v s,i to EV r σ,v s,i+1 at time t σ,v l , respectively, while uvb , respectively, represent the total upload and download bandwidth from EV r σ,v s,i to EV r σ,v s,i+1 .
Step 2: If the preceding step fails to form any fleet capable of supporting the required bandwidth for v, notify the RSU that initiated this module and terminate the execution of this module.
Step 3: The required bandwidth for v is transmitted from base stations or CF mMIMO clusters to the fleet using Li-Fi, enabling V2V communication.
Step 4: Whether EV σ passing through a segment still cannot meet the bandwidth requirements for v can be checked as follows: where t σ,v j represents the time period during which the bandwidth is insufficient for v, and dub t σ,v l and ddb t σ,v l denote the bandwidth deficit for upload and download during t σ,v j , respectively.
Step 5: The bandwidth forwarding result is communicated back to the RSU that initiated this module.

Analysis and Discussion of Simulation Results
A simulation was conducted on a personal computer equipped with an Intel Core i7 2.9 GHz CPU and 64 GB RAM to evaluate the proposed algorithm.Because communication technologies like 6G and CF mMIMO are still in their early development stages, actual data are not yet available.Consequently, this study relies on numerical validation to assess the effectiveness of the proposed algorithm.
This work references the vehicle volume statistics for New York City [35].The starting and ending points for EVs are randomly generated.The total number of vehicles on the road at any given time is aligned with the traffic density data from [35].Since a dedicated EV database is not available, this study treats the vehicles referenced in [35] as EVs.
The multimedia applications are categorized into three types: non-real-time, realtime, and emergency applications.Emergency applications, including 360 • video calls, use HEVC with reduced encoding complexity.Real-time applications, such as 2D video calls, 2D live video, and 360 • live video, also use HEVC with lower encoding complexity.Non-real-time applications, including 2D VoD and 360 • VoD, employ VVC at half the bitrate of HEVC.The usage proportions and frequencies of different video types in this study are estimated from data provided by the websites referenced in [36][37][38][39][40][41][42].
The parameters used in the proposed algorithm are detailed below.The time slot interval was set to 10 s, and each video segment had a duration of 1000 milliseconds.It was assumed that each EV had storage capacity well beyond the size of the preloaded video segments.Moreover, the number of passengers per EV varied, with possible values ranging from 1 to 5.
Tables 1-3 present the anticipated bandwidth demands for various types of 2D videos [43] and 360 • videos [44].The projected bandwidth requirements for non-realtime applications are detailed in Table 1, with VVC using half the bandwidth of HEVC for 2D and 360 • VoD.Tables 2 and 3 present the projected bandwidth requirements for real-time applications and emergency applications using HEVC, respectively, where 2D video call and 360 • video call involve bidirectional transmission.The simulation environment utilized three types of cellular base stations, sub-6GHz [45], mmWave [45,46], and THz [45,47], along with WiFi 7 [20,46] access points in a non-cellular architecture, to provide bandwidth for various applications used by EV users.Furthermore, LiFi [48] technology was implemented for V2V communication among EVs.  Figure 6 depicts the daily fluctuations in the number of EVs on the road, with vehicle counts based on traffic density data from [35].The vertical axis shows the number of EVs, while the horizontal axis indicates the time in hourly units.The data are presented in 30 min intervals, with hourly markers on the horizontal axis for clarity.As revealed in Figure 6, a sharp increase in the number of EVs is observed after 5 a.m. as people begin their morning commutes, continuing to surge until peaking at 8:30 a.m., coinciding with the typical start of the workday for many commuters.Following the 8:30 a.m.peak, the number of vehicles decreases but then stabilizes, maintaining a consistent level of around 4000 vehicles between 10:30 a.m. and 3 p.m.This steady state suggests a period of relative equilibrium in vehicle usage, likely due to people being at work and making fewer trips.In the late afternoon, starting around 3 p.m., there Following the 8:30 a.m.peak, the number of vehicles decreases but then stabilizes, maintaining a consistent level of around 4000 vehicles between 10:30 a.m. and 3 p.m.This steady state suggests a period of relative equilibrium in vehicle usage, likely due to people being at work and making fewer trips.In the late afternoon, starting around 3 p.m., there is another rise in the number of EVs.This second increase aligns with the end of the workday, as people begin their commutes back home or to other evening activities.The vehicle count reaches another peak at 6 p.m., reflecting the high volume of evening travel.After this evening peak, the number of vehicles on the road begins to decline again.This downward trend continues through the night, reaching its lowest point during the early morning hours.This pattern suggests that most EVs are idle from late night to early morning, likely because people are at home instead of traveling or the vehicles are being charged during these hours.
Figure 7 illustrates the usage of multimedia applications by EV users throughout the day.The usage numbers for each application are estimated from data provided by the websites referenced in [36][37][38][39][40][41][42] and adjusted according to the fluctuations in the number of EVs during different time periods.These applications fall into six categories: emergency applications, such as 360 • video calls; real-time applications, including 2D video calls, 2D live video, and 360 • live video; and non-real-time applications, such as 2D VoD and 360 • VoD.The usage patterns of these multimedia applications are closely linked to the fluctuations in the number of EVs depicted in Figure 6, indicating a strong correlation between vehicle activity and multimedia consumption.As illustrated in Figure 7, the low number of EVs correlates with lower multimedia application usage in the early morning hours.This is likely due to fewer people being on the road and therefore less demand for entertainment or communication via multimedia applications.As the number of vehicles rises from 5 a.m.onwards, corresponding to the start of the morning commute, the usage of all applications increases.This increase continues until it peaks during the morning rush hour at 8:30 a.m.. Users likely engage with multimedia applications to kill time, stay informed, or be entertained while the EV is in motion.
After the morning peak, multimedia application usage tends to decrease as the number of EVs stabilizes.However, the number of EVs starts to rise again at around 3 p.m., and there is a corresponding increase in multimedia application usage.This trend continues until it reaches another peak during the evening rush hour at 6 PM, similar to the morning peak.During these times, users frequently engage with multimedia applications, whether during their commutes home or while participating in evening activities.As illustrated in Figure 7, the low number of EVs correlates with lower multimedia application usage in the early morning hours.This is likely due to fewer people being on the road and therefore less demand for entertainment or communication via multimedia applications.As the number of vehicles rises from 5 a.m.onwards, corresponding to the start of the morning commute, the usage of all applications increases.This increase continues until it peaks during the morning rush hour at 8:30 a.m.Users likely engage with multimedia applications to kill time, stay informed, or be entertained while the EV is in motion.
After the morning peak, multimedia application usage tends to decrease as the number of EVs stabilizes.However, the number of EVs starts to rise again at around 3 p.m., and there is a corresponding increase in multimedia application usage.This trend continues until it reaches another peak during the evening rush hour at 6 PM, similar to the morning peak.During these times, users frequently engage with multimedia applications, whether during their commutes home or while participating in evening activities.
Notably, VoD applications are more frequently used throughout the day compared to live video and emergency applications.The flexibility of VoD allows users to pause, fast-forward, and replay content at their convenience, which is particularly appealing for commuters with unpredictable schedules.Additionally, the wider variety of content available on VoD platforms attracts a larger audience.
In contrast, live video applications are used less frequently because they are tied to specific broadcast times, making them less convenient for users with varying schedules.Furthermore, 360 • videos are less commonly used compared to 2D videos due to their higher production complexity and greater network requirements.The immersive nature of 360 • videos, while appealing, demands more bandwidth and better connectivity, which may not always be available to EV users on the go.
Figure 8 illustrates the bandwidth requirements for six different multimedia applications: 2D VoD, 360 • VoD, 2D live video, 360 • live video, 2D video calls, and 360 • video calls.These requirements are determined based on the usage numbers of multimedia applications during different time periods.The video resolution and frame rate for each application type are randomly selected from the corresponding video categories in Tables 1-3.As illustrated by the red, gray, and blue curves in Figure 8, the bandwidth demand for 2D video is relatively low, as outlined in Tables 1 and 2, even though 2D video is more frequently used.In other words, the bandwidth needs for 2D video calls, 2D live video, and 2D VoD are noticeably lower than those for the three 360 • video applications.3.As illustrated by the red, gray, and blue curves in Figure 8, the bandwidth demand for 2D video is relatively low, as outlined in Tables 1 and 2, even though 2D video is more frequently used.In other words, the bandwidth needs for 2D video calls, 2D live video, and 2D VoD are noticeably lower than those for the three 360° video applications.As shown by the green, tangerine, and yellow curves in Figure 8, 360° videos demand significant bandwidth to deliver immersive 3D content, providing users with a more engaging experience.As a result, the bandwidth requirements for 360° VoD, 360° live video, and 360° video calls are higher compared to those for 2D videos.This increased demand is due to the higher resolution and larger data volumes needed to create the 360° field of view, which enhances user immersion but also significantly increases the amount of data that must be transmitted.
Moreover, non-real-time applications, like 2D VoD and 360° VoD, use highly compressed VVC to minimize bandwidth usage.This advanced compression technology al- As shown by the green, tangerine, and yellow curves in Figure 8, 360 • videos demand significant bandwidth to deliver immersive 3D content, providing users with a more engaging experience.As a result, the bandwidth requirements for 360 • VoD, 360 • live video, and 360 • video calls are higher compared to those for 2D videos.This increased demand is due to the higher resolution and larger data volumes needed to create the 360 • field of view, which enhances user immersion but also significantly increases the amount of data that must be transmitted.
Moreover, non-real-time applications, like 2D VoD and 360 • VoD, use highly compressed VVC to minimize bandwidth usage.This advanced compression technology allows for high-quality video playback without requiring excessive data transmission.Consequently, the bandwidth demand for VoD, despite its higher viewing rates, is not significantly greater than that of other applications.This efficiency in data compression means that users can enjoy high-quality video content with less strain on network resources.
Conversely, real-time applications, such as video calls, necessitate the simultaneous uploading and downloading of video streams, which require more bandwidth.This bidirectional data flow leads to relatively higher bandwidth demands compared to VoD applications.Specifically, 2D video calls, while less bandwidth-intensive than their 360 • counterparts, still require more bandwidth than VoD due to the need for real-time interaction and low latency to maintain a seamless communication experience.
The disparity in bandwidth requirements between 2D and 360 • applications is further accentuated in live video scenarios, as shown in Figure 8; 360 • live video not only demands high bandwidth for transmitting large amounts of data in real-time but also requires robust network infrastructure to handle the simultaneous streaming to multiple users.This makes 360 • live video one of the most bandwidth-intensive applications, necessitating advanced network solutions to support widespread use.
Figure 9 illustrates the bandwidth allocated to each multimedia application before implementing the algorithm proposed in this study.In the early morning hours, when user bandwidth demand is low, the bandwidth requirements for all applications are adequately met.However, as the day progresses and the number of EVs increases, the use of multimedia applications grows correspondingly, resulting in a substantial rise in bandwidth demand.This escalation leads to periods during the daytime when users experience insufficient bandwidth availability.
Sensors 2024, 23, x FOR PEER REVIEW 24 of 33 Figure 9 illustrates the bandwidth allocated to each multimedia application before implementing the algorithm proposed in this study.In the early morning hours, when user bandwidth demand is low, the bandwidth requirements for all applications are adequately met.However, as the day progresses and the number of EVs increases, the use of multimedia applications grows correspondingly, resulting in a substantial rise in bandwidth demand.This escalation leads to periods during the daytime when users experience insufficient bandwidth availability.As depicted in Figure 9, due to the lower number of active EVs and the resulting minimal usage of multimedia applications during the early morning hours, the overall demand for bandwidth remains manageable.This period typically experiences surplus bandwidth, ensuring that users can access their desired content without interruption.
However, starting from 5 a.m., the increase in active EVs is accompanied by a rise in the usage of multimedia applications, such as live video, VoD, and video calls.This surge As depicted in Figure 9, due to the lower number of active EVs and the resulting minimal usage of multimedia applications during the early morning hours, the overall demand for bandwidth remains manageable.This period typically experiences surplus bandwidth, ensuring that users can access their desired content without interruption.
However, starting from 5 a.m., the increase in active EVs is accompanied by a rise in the usage of multimedia applications, such as live video, VoD, and video calls.This surge in demand continues throughout the morning rush hour, peaking at around 8:30 a.m., when the need for bandwidth reaches its highest point due to widespread commuter activity and multimedia consumption.
Notably, starting from around 6 a.m., the bandwidth-allocation curve tends to flatten out.During this period, there is a sustained and significant demand for multimedia applications.However, the allocated bandwidth for EV passengers often reaches its maximum limit due to the confined bandwidth supply in vehicular networks.
Despite the overall increase in bandwidth demand throughout the day, Figure 9 illustrates that there are periods when the allocated bandwidth may not sufficiently meet the needs of all users.This discrepancy can lead to degraded service quality, such as buffering during video playback or dropped connections during video calls, impacting user experience.
Figure 10 visualizes the improved approach to bandwidth allocation implemented through our algorithm, demonstrating significant improvements across various multimedia applications.The improvements are attributed to several key modules of the proposed work that aim to optimize bandwidth utilization and enhance user experience in diverse usage scenarios.
A standout feature of the proposed work is the "Emergency/Real-time Application Bandwidth Assignment" module, which prioritizes bandwidth allocation for critical applications, such as 360 • video calls from CF mMIMO access points.Additionally, when emergency applications cannot obtain sufficient bandwidth, the module reallocates bandwidth that was originally designed for non-real-time applications to emergency applications.This module ensures that even during peak demand periods, resources are allocated efficiently, significantly enhancing the availability of bandwidth for emergency application needs.A standout feature of the proposed work is the "Emergency/Real-time Application Bandwidth Assignment" module, which prioritizes bandwidth allocation for critical applications, such as 360° video calls from CF mMIMO access points.Additionally, when emergency applications cannot obtain sufficient bandwidth, the module reallocates band- Additionally, the algorithm incorporates the "V2V Bandwidth Forwarding Module", leveraging V2V communication to dynamically redistribute bandwidth.By utilizing connectivity between nearby vehicles, this module optimizes the allocation of bandwidth from base stations and access points across different areas.This approach maximizes the fulfillment of bandwidth demands for all multimedia applications, ensuring consistent performance and reliability throughout EV environments.
Overall, Figure 10 underscores how the implemented algorithm revolutionizes bandwidth management in EV environments.By prioritizing critical applications, optimizing resource allocation through V2V communication, the algorithm significantly enhances bandwidth availability and improves the overall multimedia experience for users.These advancements are essential for meeting the increasing demands of multimedia applications in dynamic and densely populated EV settings, ensuring reliable and efficient multimedia usage across various scenarios.
Figure 11 illustrates the gap between the actual bandwidth allocated to EV users' applications and their expected bandwidth requirements before the implementation of the proposed work.As observed in Figure 11, the bandwidth needs for all application types are met from 11:30 p.m. to 5:30 a.m.However, as user bandwidth demand increases, the disparity between the available bandwidth and the expected requirements widens.Prior to implementing the algorithm, bandwidth allocation followed a first-come, first-served approach, which did not account for bandwidth-allocation priorities.Consequently, the largest gap is seen in the emergency application, 360° video calls, which has the highest bandwidth demand.In contrast, the gap for 2D video, which requires less bandwidth, is less significant.
Figure 12 highlights the differences between the allocated bandwidth and the expected bandwidth requirements for EV users' applications after the implementation of the proposed work.With our proposed algorithm in place, there is a noticeable improvement in the bandwidth assigned to EV users' applications.From 9:30 p.m. to 6:30 a.m., applications' bandwidth needs are consistently satisfied.Even during peak demand periods, the difference between the assigned bandwidth and applications' needs is substantially reduced, attributed to the V2V bandwidth forwarding strategy that enhances overall bandwidth utilization.Prior to implementing the algorithm, bandwidth allocation followed a first-come, firstserved approach, which did not account for bandwidth-allocation priorities.Consequently, the largest gap is seen in the emergency application, 360 • video calls, which has the highest bandwidth demand.In contrast, the gap for 2D video, which requires less bandwidth, is less significant.
Figure 12 highlights the differences between the allocated bandwidth and the expected bandwidth requirements for EV users' applications after the implementation of the proposed work.With our proposed algorithm in place, there is a noticeable improvement in the bandwidth assigned to EV users' applications.From 9:30 p.m. to 6:30 a.m., applications' bandwidth needs are consistently satisfied.Even during peak demand periods, the difference between the assigned bandwidth and applications' needs is substantially reduced, attributed to the V2V bandwidth forwarding strategy that enhances overall bandwidth utilization.Additionally, Figure 12 illustrates a significant reduction in the bandwidth gap for emergency applications, such as 360° video calls.This improvement is achieved by prioritizing bandwidth usage for emergency applications and reallocating bandwidth from other types of applications to emergency ones.Other applications also benefit from V2V communication, which redistributes bandwidth from less congested base stations or access points at less congested road segments, thereby reducing the gap between assigned bandwidth and their requirements.
Figure 13 illustrates the number of playback interruptions for each type of application caused by insufficient bandwidth before implementing the algorithm.During the period from 11:30 p.m. to 5:30 a.m., when bandwidth requirements are generally met, users receive adequate bandwidth to ensure the smooth playback of their applications.This period sees minimal interruptions, indicating that the existing bandwidth allocation is sufficient for the user demand during these hours.Additionally, Figure 12 illustrates a significant reduction in the bandwidth gap for emergency applications, such as 360 • video calls.This improvement is achieved by prioritizing bandwidth usage for emergency applications and reallocating bandwidth from other types of applications to emergency ones.Other applications also benefit from V2V communication, which redistributes bandwidth from less congested base stations or access points at less congested road segments, thereby reducing the gap between assigned bandwidth and their requirements.
Figure 13 illustrates the number of playback interruptions for each type of application caused by insufficient bandwidth before implementing the algorithm.During the period from 11:30 p.m. to 5:30 a.m., when bandwidth requirements are generally met, users receive adequate bandwidth to ensure the smooth playback of their applications.This period sees minimal interruptions, indicating that the existing bandwidth allocation is sufficient for the user demand during these hours.
However, as the number of EV users increases during the morning commute, bandwidth resource contention becomes a significant issue.The growing demand for bandwidth leads to more EV users' applications being unable to acquire sufficient bandwidth, resulting in a marked increase in playback interruptions across various applications.This deteriorated quality of EV users' experiences underscores the need for a more efficient bandwidth-allocation strategy.
Figure 14 contrasts the number of playback interruptions for each type of application after implementing the proposed algorithm.A significant reduction in interruptions is observed across all time periods for most of EV users' applications.Specifically, during the morning and evening peak demand periods, five of the six types of applications see a substantial decline in the number of playback interruptions, while only 2D VoD shows a slight decrease in playback interruptions.However, as the number of EV users increases during the morning commute, bandwidth resource contention becomes a significant issue.The growing demand for bandwidth leads to more EV users' applications being unable to acquire sufficient bandwidth, resulting in a marked increase in playback interruptions across various applications.This deteriorated quality of EV users' experiences underscores the need for a more efficient bandwidth-allocation strategy.
Figure 14 contrasts the number of playback interruptions for each type of application after implementing the proposed algorithm.A significant reduction in interruptions is observed across all time periods for most of EV users' applications.Specifically, during the morning and evening peak demand periods, five of the six types of applications see a substantial decline in the number of playback interruptions, while only 2D VoD shows a slight decrease in playback interruptions.Notably, the interruptions for emergency applications, such as 360 • video calls, approach zero between 9:30 p.m. and 6:30 a.m. and between 10:30 a.m. and 2:30 p.m.This represents the lowest interruption rate among all types of multimedia applications.This improvement is mainly achieved by prioritizing bandwidth allocation for different applications, effectively minimizing interruptions for emergency and real-time applications.Notably, the interruptions for emergency applications, such as 360° video calls, approach zero between 9:30 p.m. and 6:30 a.m. and between 10:30 a.m. and 2:30 p.m..This represents the lowest interruption rate among all types of multimedia applications.This improvement is mainly achieved by prioritizing bandwidth allocation for different appli- In addition, the "Multimedia Application Bandwidth Adjustment" module adjusts parameters, such as the frame rate and resolution, based on the type of multimedia application to meet the specific needs of EV users' applications.Consequently, even during peak bandwidth demand periods, when EV users' applications experience a bandwidth deficit, this module reduces the frame rate and resolution of the applications to decrease the bandwidth required.This adjustment effectively prevents interruptions or buffering during multimedia usage, thereby improving the overall user experience.
Figure 15 presents a comparison of the overall bandwidth requirements for all multimedia applications during a day before and after the implementation of the proposed work.During the early hours, from midnight to 5:30 a.m., bandwidth demand remains relatively low across all multimedia applications.Consequently, existing bandwidth resources generally meet these demands adequately without requiring intervention from the proposed algorithm.However, as time progresses, typically starting around the morning hours, the bandwidth demand of applications begins to increase.This increase in demand can escalate rapidly, especially during peak periods, such as morning and evening rush hours.Often, this surge surpasses the maximum capacity of congested CF mMIMO wireless access points and base stations, resulting in insufficient bandwidth for many EV passengers' applications.This creates a notable disparity between the demand for bandwidth and its availability, particularly in densely populated or high-traffic areas.
Before the implementation of our proposed algorithm, bandwidth was allocated using a first-come, first-served approach.This method did not prioritize critical applications and lacked a V2V bandwidth scheduling strategy, often leading to insufficient bandwidth for emergency applications and the inefficient use of available resources.On the contrary, the algorithm introduced in this study effectively addresses these bandwidth limitations within congested V2X networks.A critical mechanism is the V2V bandwidth scheduling, facilitated by LiFi technology, which dynamically redistributes bandwidth.This approach optimizes resource use by reallocating bandwidth from less congested w CF mMIMO wireless access points and base stations to vehicles on congested roads via V2V communication.By leveraging V2V communication, the algorithm efficiently schedules bandwidth, ensuring that EV users on busy routes have access to enhanced resources.
Facilitated by the proposed algorithm, there is a substantial increase in available bandwidth for EV users' applications, particularly noticeable from 6 a.m. to 23 p.m. as shown in Figure 15.A 47% increase is achieved in assigned bandwidth, effectively miti-0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 However, as time progresses, typically starting around the morning hours, the bandwidth demand of applications begins to increase.This increase in demand can escalate rapidly, especially during peak periods, such as morning and evening rush hours.Often, this surge surpasses the maximum capacity of congested CF mMIMO wireless access points and base stations, resulting in insufficient bandwidth for many EV passengers' applications.This creates a notable disparity between the demand for bandwidth and its availability, particularly in densely populated or high-traffic areas.
Before the implementation of our proposed algorithm, bandwidth was allocated using a first-come, first-served approach.This method did not prioritize critical applications and lacked a V2V bandwidth scheduling strategy, often leading to insufficient bandwidth for emergency applications and the inefficient use of available resources.On the contrary, the algorithm introduced in this study effectively addresses these bandwidth limitations within congested V2X networks.A critical mechanism is the V2V bandwidth scheduling, facilitated by LiFi technology, which dynamically redistributes bandwidth.This approach optimizes resource use by reallocating bandwidth from less congested w CF mMIMO wireless access points and base stations to vehicles on congested roads via V2V communi-cation.By leveraging V2V communication, the algorithm efficiently schedules bandwidth, ensuring that EV users on busy routes have access to enhanced resources.
Facilitated by the proposed algorithm, there is a substantial increase in available bandwidth for EV users' applications, particularly noticeable from 6 a.m. to 23 p.m. as shown in Figure 15.A 47% increase is achieved in assigned bandwidth, effectively mitigating network resource contention issues and improving the overall user experience with reliable multimedia application performance.Figure 15 also demonstrates how the proposed algorithm revolutionizes bandwidth management in congested V2X networks.By optimizing resource allocation through advanced V2V communication and LiFi technology and efficiently managing CF mMIMO access points and base station allocated bandwidth, the algorithm significantly enhances bandwidth-utilization efficiency.This proactive approach effectively addresses bandwidth limitations, resulting in an enriched multimedia experience for EV users across various usage scenarios and timeframes.

Conclusions
Although numerous studies have proposed algorithms for multimedia transmission in V2X networks, the potential of emerging wireless communication technologies remains largely unexplored.This study aims to integrate various cutting-edge technologies, including THz, mmWave, sub-6GHz cellular base stations, and CF mMIMO Wi-Fi 7 access points.The objective is to deliver ultra-high transmission rates, seamless connectivity, and minimal interference for EV users in V2X networks.Additionally, the study investigates the use of Li-Fi technology for vehicular applications, leveraging it to enhance V2V communication and meet the bandwidth requirements of other vehicles.
This study validates the proposed mechanisms through a detailed simulation analysis, showing an average bandwidth increase of 47% for EV users' applications during peak times.The proposed mechanisms include prioritizing bandwidth for emergency and realtime applications, implementing a pre-downloading strategy for non-real-time applications, and using V2V communication for bandwidth relay from less congested access points or base stations.This approach ensures that EV users' applications have adequate bandwidth during high-demand periods, facilitating smooth multimedia playback.
In summary, compared to the existing literature, this study introduces a range of emerging wireless technologies into V2X networks, significantly boosting user bandwidth through V2V communication and addressing the prioritization of various application types.The proposed algorithm effectively manages bandwidth contention among EV passengers and ensures uninterrupted multimedia application playback during peak demand.By meeting the needs of most EV passengers, the algorithm enhances overall service satisfaction and positions itself as a leader in bandwidth management within the evolving field of EV connectivity.
Due to the absence of actual data for testing, this study is limited to numerical validation.Once actual data become accessible in the future, further validation will be conducted to verify the feasibility of the proposed algorithm.Moreover, as EV adoption becomes more prevalent, incorporating real-world data on EV charging times into the simulations will be considered to enhance their accuracy and relevance to actual conditions.

Figure 1 .
Figure 1.Enhancing differentiated streaming services in diverse V2X networks: a scenario.Figure 1. Enhancing differentiated streaming services in diverse V2X networks: a scenario.

Figure 1 .
Figure 1.Enhancing differentiated streaming services in diverse V2X networks: a scenario.Figure 1. Enhancing differentiated streaming services in diverse V2X networks: a scenario.This study categorizes the multimedia applications used by EV passengers into six types: 2D video on demand (VoD), 2D video calls, 2D live video, 360 • VoD, 360 • video calls, and 360 • live video.These applications are further divided into three categories based

Figure 2 .
Figure 2. Flow charts of "Real-time Traffic and Travel Time Calculation" module and "Multimedia Application Bandwidth Adjustment" module.

represents the time spent
by the EV at intermediate stopping point c σ l,i,h σ l,i

Figure 4 .
Figure 4. Flow chart of "Non-Real-Time Application Download" module.

Figure 4 .
Figure 4. Flow chart of "Non-Real-Time Application Download" module.

Figure 6 .
Figure 6.Volume of EVs throughout a day.

Figure 7 .
Figure 7. Counts of multimedia applications initiated by passengers in EVs throughout a day.

Figure 7 .
Figure 7. Counts of multimedia applications initiated by passengers in EVs throughout a day.

Figure 8 .
Figure 8. Daily bandwidth demands of multimedia applications.

Figure 8 .
Figure 8. Daily bandwidth demands of multimedia applications.

Figure 9 .
Figure 9. Bandwidth assignments for multimedia applications before implementing the proposed work.

Figure 9 .
Figure 9. Bandwidth assignments for multimedia applications before implementing the proposed work.

Sensors 2024 ,
23, x FOR PEER REVIEW 25 of 33 work that aim to optimize bandwidth utilization and enhance user experience in diverse usage scenarios.

Figure 10 .
Figure 10.Bandwidth assignments for multimedia applications after implementing the proposed work.

Figure 10 .
Figure 10.Bandwidth assignments for multimedia applications after implementing the proposed work.

Figure 11 .
Figure 11.Difference between allocated bandwidth and expected bandwidth needs before implementing the proposed algorithm.

Figure 11 .
Figure 11.Difference between allocated bandwidth and expected bandwidth needs before implementing the proposed algorithm.

Figure 12 .
Figure 12.Difference between allocated bandwidth and expected bandwidth needs after implementing the proposed algorithm.

Figure 12 .
Figure 12.Difference between allocated bandwidth and expected bandwidth needs after implementing the proposed algorithm.

Figure 13 .
Figure 13.Number of playback interruptions for each type of application before implementing the proposed algorithm.

Figure 13 .
Figure 13.Number of playback interruptions for each type of application before implementing the proposed algorithm.

Sensors 2024 , 33 Figure 14 .
Figure 14.Number of playback interruptions for each type of application after implementing the algorithm.

Figure 14 .
Figure 14.Number of playback interruptions for each type of application after implementing the algorithm.

Sensors 2024 , 33 Figure 15 .
Figure 15.Contrast of bandwidth requirements and assigned bandwidth before and after algorithm implementation.

Figure 15 .
Figure 15.Contrast of bandwidth requirements and assigned bandwidth before and after algorithm implementation.
• video calls, are essential in scenarios like remote surgery in an ambulance.The broader range of visible angles provided by 360 • video calls is crucial for performing precise operations, ensuring that medical professionals can view and assess the situation comprehensively.•Real-timeapplications include 2D video calls, 2D live video, and 360 • live video • Non-real-time applications include 2D VoD and 360 • VoD.
Figure 4 illustrates the flowchart of this module, and the execution steps are outlined below:

Table 1 .
Anticipated bandwidth demands for non-real-time applications using VVC.

Table 2 .
Anticipated bandwidth requirements for real-time applications using HEVC.

Table 3 .
Anticipated bandwidth requirements for emergency applications using HEVC.
Table 4 details these wireless communication technologies' maximum transmission distance and bandwidth.

Table 4 .
Maximum communication distance and bandwidth for these wireless communication technologies.